The present application relates to access application services in a network, and more particularly to user friendly provision of end user connection, to an application service, which is optimally based on the network dynamic conditions and application requirements in a network.
Background: Path Computation Elements (PCE) and Applications
As Internet based applications grow rapidly, network service providers need to support different bandwidth-on-demand services. Examples include large file downloading, on-line video gaming, and on-line conferencing. These kinds of applications sometimes require a peer to peer connection with a dedicated bandwidth between a user and an application; and the application could be offered concurrently on multiple servers that are physically attached to the network at different locations. The user can initiate a connection request to any one of these servers for the application service from anywhere within the network.
FIG. 3 illustrates an example: a user attaches to a network at St. Louis; several servers attach to the network at New York, Chicago, Dallas, and Los Angles, respectively. Assume all servers are running a “StarWar” application. When the user wants to play this online video game, the game proxy program on the user computer must connect to the network with adequate bandwidth. In this example, suppose that the best service would occur if the Chicago site is used for the connection. However, how is this optimal connection to be discovered. If the user or user application specifies a different target address (e.g. Los Angeles), the user's program will be attached to that server, even if the server is overloaded or the connection routes to it have bottlenecks.
Connection between two network entities requires path computation, Path computation is especially challenging in today's large, multi-domain, multi-region and multi-layers networks. A network can have multiple domains, because a path might cross between the networks of different service providers. A network can include multiple regions, since connected entities might be located at different geographic areas. A network can have multiple layers, because an IP network might be built on Multi-Protocol Label Switching (MPLS) or Generalized Multi Protocol Label Switching (GMPLS) based optical network networks.
The IETF has proposed, in RFC 4655, a path computation solution in large, multi-domain and multi-layer networks with special computational components and cooperation between the elements in different domains. A Path. Computation Element (“PCE”) is an entity that is capable of computing a network path or route based on a network graph, and of applying computational constraints during the computation. The PCE entity is an application that can be located within a network node or component, on an out-of-network server, etc.
FIG. 4 illustrates a PCE based network architecture. The connection request comes to a Path Computation Client (“PCC”) first. A PCC (not shown in FIG. 4) is normally co-located with a Network Node or Network Element (“NE”). A PCC is a client application requesting a path computation to be performed by the PCE, PCC then sends a path computation request to a PCE through the PCE protocol (“PCEP”). PCE computes a path and sends the selected path information back to PCC using PCEP.
FIG. 4 shows two PCEs in the networks. Each is capable of computing a path within its own network domain. A domain is any collection of network elements within a common sphere of address management or path computation responsibility. Examples of domains include IGP areas, Autonomous Systems (ASes), and multiple ASes within a Service Provider network. Domains of path computation responsibility may also exist as sub-domains of areas or ASes. When a connection is across two domains (or sub-domains), both PCEs may get involved with the path computation process to find an inter-domain path.
Overview, of the PCE-Based Architecture Composite PCE
FIG. 5 shows the components of a typical composite PCE node (that is, a NE such as router also implements the PCE functionality) that utilizes path computation. The routing protocol is used to exchange TE information from which the Traffic Engineering Database (“TED”) is constructed. Service requests to provision TE LSPs (Traffic Engineering Label Switching Paths) are received by the node and converted into signaling requests, but this conversion may require path computation that is requested from a PCE. The PCE operates on the TED subject to local policy in order to respond with the requested path.
Note that the routing adjacency between the composite PCE and any other router may be performed by means of direct connectivity or any tunneling mechanism.
External PCE
FIG. 6 shows a PCE that is external to the requesting network element. A service request is received by the head-end node, and before it can initiate signaling to establish the service, it makes a path computation request to the external PCE. The PCE uses the TED subject to local policy as input to the computation and returns a response.
Note that in this case, the node that supports the PCE function may also be an LSR (Label Switching Router) or router performing forwarding in its own right (i.e., it may be a composite PCE node), but those functions are purely orthogonal to the operation of the function in the instance being considered here.
PCE Interface Requires Network Addresses
Normally a PCE requires two explicitly identified addresses to compute a route. In the “StarWar” example above, the PCE requires a source address, i.e. the network address of the player the user is using (for example, a mobile phone or laptop PC), and a destination address, the network address of the host of the game server. This requirement is neither flexible and nor user-friendly. A user should not be required to have the knowledge of network topology such that she knows the application server's addresses.
Even if the user is very knowledgeable about the network topology, he still has no knowledge of the connectivity or traffic conditions of the network and application servers to make an optimal decision to select a destination address. To make an optimal decision, he will have to find, the addresses of all the servers hosting the requested application, then send a request with the address of each server to the network to let PCE compute an optimal path, to each server. Finally, he compares multiple paths to determine which one offers the optimal path to the requested service.
Path Selection Policy
A PCE may have a local policy that impacts path computation and selection in response to a path computation request. Such policy may act on information provided by the requesting PCC. The result of applying such policy includes, for example, rejection of the path computation request, or provision of a path that does not meet all of the requested constraints. Further, the policy may support administratively configured paths, or selection, among transit providers. Inclusion of policy within PCE may simplify the application of policy within the path computation/selection process.
Similarly, a PCC may apply local policy to the selection of a PCE to compute a specific path, and to the constraints that are requested.
In a PCE context, the policy may be sensitive to the type of path that is being computed. For example, a different set of policies may be applied for an intra-area or single-layer path than would be provided for an inter-area or multi-layer path.
Again, how a user finds out and stores local policy about the application the user is using are outside the scope of the PCE architecture. For instance, applications have different requirements on uplink and downlink bandwidths, and application servers support various maximum number of users. PCE specifications in IETF did not address those issues, but they are nevertheless very important for the growth of Internet applications based on PCE architecture.